Calling gdk_device_get_direction can trigger a
notify::direction emissions, since the X11 backend
determines the direction on demand. Prevent that by
forcing the direction to be determined ahead of time.
Corey Berla [Tue, 29 Nov 2022 00:32:52 +0000 (16:32 -0800)]
atspicontext: Cache empty atspi bus address
We are caching the bus address as data on the display object when it
exists, but fail to set the data when the bus address doesn't exist.
That causing excessive calls to GetAddress when the accesssbility
bus doesn't exist. Make sure to cache a non-existent accessibility
bus by setting the "" string.
Corey Berla [Sun, 27 Nov 2022 22:12:36 +0000 (14:12 -0800)]
atspicontext: Log failure to connect to a11y
GTK depends on the a11y infrastructure to be in place unless GTK_A11Y is
set to none. It appears that despite that, users attempt to
get around the a11y requirement without setting GTK_A11Y.
This can cause, amongst other issues, performance problems
with gtk applications. Log failure to connect to the a11y
bus.
Simon McVittie [Thu, 24 Nov 2022 10:25:43 +0000 (10:25 +0000)]
subprojects: Pin GLib to version 2.74.x
GLib 2.74.x and GTK 4.8.x both correspond to the GNOME 43 cycle. Keeping
GLib on the 2.74.x branch avoids a CI regression when GLib git main
depends on a newer Meson version than the one GTK's CI installs, which
has happened in 2.75.x as a result of GNOME/glib!3077.
Carlos Garnacho [Fri, 18 Nov 2022 14:02:22 +0000 (15:02 +0100)]
gdksurface: Do not consider GDK_TOUCH_END/CANCEL as popup-dismiss worthy
GDK_TOUCH_END deserves the same treatment than GDK_BUTTON_RELEASE, since it's
subject to the same circumstances (popping up a menu on long press would be
immediately dismissed on release if we handled them there). Ideally, we would
want to match releases that we obtained a press for while grabbed, but as
the popup is also dismissed on GDK_BUTTON_PRESS/GDK_TOUCH_BEGIN, there's no
use for this tracking.
And GDK_TOUCH_CANCEL sounds weird as a reason to dismiss popups, just like
crossing events would.
Carlos Garnacho [Fri, 18 Nov 2022 12:57:02 +0000 (13:57 +0100)]
gtktext: Claim gesture more selectively
Even though button 1 (or touch down) presses do most often have
an effect in one way or another (starting drag, moving focus,
starting selection, ...), there is one situation that they do
immediately nothing: When clicking on the entry does not move
the text caret around. Dragging might start a selection, but
the entry did not do anything just yet, and an immediate
button/touch release should remain at "did nothing".
And that is precisely the hint that the Wayland IM context's click
gesture takes, clicks that do not scroll nor move the caret around,
having the GtkText not claim the gesture in that situation makes
the IM gesture able to do its thing without in-fighting.
This is typically not a problem when the GtkText is embedded in
another GtkEditable implementation (e.g. GtkEntry), since the
IM gesture is inactive and capturing from the parent widget, so
gets a pass that it otherwise doesn't get when both gestures are
in the same widget. This makes it work regardless of GtkText not
being a child of a composite widget, like NautilusQueryEditor
and AdwRowEntry.
Carlos Garnacho [Wed, 19 Oct 2022 10:46:09 +0000 (12:46 +0200)]
gdk/wayland: Use serial of the latest implicit grab available
When getting the serial for primary/clipboard selections we used a
function that largely relied on a GdkEvent being passed. We have
another available function that looks up the most recent serial
given the ongoing touch/tablet input as well.
This is the second best, compared to actually knowing the
input/device from the event that was received by the UI an triggered
the clipboard operation, and is already in use in other places
(e.g. window dragging). It is valid for these situations too.
Adam Williamson [Wed, 2 Nov 2022 00:26:29 +0000 (17:26 -0700)]
focus: fall back to old behaviour if we didn't focus anything
8455b9ac74 seems to have introduced a problem where we can wind
up focusing no widget at all if the `while (parent)` loop doesn't
find a widget it can successfully move the focus to. This 'fixes'
that by falling back to doing the previous thing if we make it
all the way through that loop without moving the focus. Thanks to
@coreyberla for a hint to improve the implementation.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Carlos Garnacho [Wed, 2 Nov 2022 16:11:10 +0000 (17:11 +0100)]
gdk/wayland: Fix button mask calculation on button events
There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
assigned. This is now calculated on the (continuous) BTN_ evcodes
so it is guaranteed that the next 2 physical buttons (i.e.
back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
modifier mask that they didn't belong to. It is now checked hard
that only the first 5 buttons enable a modifier flag.
Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.
Luca Bacci [Thu, 10 Nov 2022 08:22:02 +0000 (09:22 +0100)]
GdkWin32: Do not use MA_NOACTIVATEANDEAT
GTK knows when a surface is modally blocked and automatically drops
button press and release events, so do not block input in advance
from WM_MOUSEACTIVATE.
Matthias Clasen [Tue, 18 Oct 2022 18:23:22 +0000 (14:23 -0400)]
editablelabel: Defer changes on focus-out
We can get spurious focus-out/-in pairs when
the editable label is in a popover that gets
a Wayland keyboard enter event as a result of
clicking the editable label.
A timeout isn't a great solution, but nothing
better is available right now.
listbase: Grab focus on items instead of container
The container view itself being focusable makes keyboard navigation
slower by adding a useless focus step.
It also means if an item gets removed, the focus jumps back to the view,
instead of jumping to the next item, as seen in nautilus bug report:
https://gitlab.gnome.org/GNOME/nautilus/-/issues/2489
Instead of making the GtkListBase container itself focusable, override
the .grab_focus() vfunc. This way, calling gtk_widget_grab_focus() on
the view container keeps working sucessfully, but focuses the focus
item directly instead.
This is particularly useful to have because applicaiton authors do
not have direct acess to this class's children, so they can't call
gtk_widget_grab_focus() on them directly.
Matthias Clasen [Mon, 17 Oct 2022 19:10:51 +0000 (15:10 -0400)]
window: Don't focus invisible widgets
Only clear a queued move_focus if the widget
we are focusing is actually visible.
This was happening in some cases when popovers
are dismissed by clicking outside, and it was
causing us to miss proper focus updates that
were already queued.
That commit did two things:
1) Move the focus update to after-paint time
2) Change from grabbing focus to the visible parent
to calling move_focus (TAB)
The second part did have the unintended consequence
of moving focus laterally.
Jonas Ådahl [Fri, 30 Sep 2022 07:26:55 +0000 (09:26 +0200)]
toplevel-size: Report zero bounds as infinite
Empty/zero bounds are sent by the Wayland compositor if there are no
valid bounds to report, e.g. if there are no connected monitors. Report
this to GTK, which uses this to clamp calculated sizes, as INT_MAX, so
that clamping isn't done until there are actual valid bounds to clamp
to.
This fixes clients sometimes shrinking to their minimum size during
hotplugs or after having suspended the session.
Jonas Ådahl [Fri, 30 Sep 2022 07:30:30 +0000 (09:30 +0200)]
surface/wayland: Handle no current monitor when calculating bounds
We shouldn't assume there is always a monitor to derive bounds from.
If there is no monitor, pass empty bounds, as this matches what
xdg_toplevel.configure_bounds do in this case.
This is an experiment to see if I can keep up with
doing post-release version bumps, so git snapshots
will always have a different version from released
tarballs.
"left of right" should be "left or right".
There's a small (subjective?) English nit in there as well: I believe
that buttons are placed (for example) "on the right" rather than "at the
right".
There is nothing particularly specific to drawables
in there (and we don't have that concept anymore),
so just name the source file to match the header.
Easier for everybody.
projects / gtk4.git / log